作者：吴业亮 博客：wuyeliang.blog.csdn.net

一、IO落盘原理

一个I/O请求，从应用层到底层块设备，路径如下图所示：

从上图可以看出IO路径是很复杂的。我们将IO路径简化一下：

一个I/O请求进入block layer之后，可能会经历下面的过程： • Remap: 可能被DM(Device Mapper)或MD(Multiple Device, Software RAID) remap到其它设备

• Split: 可能会因为I/O请求与扇区边界未对齐、或者size太大而被分拆(split)成多个物理I/O

• Merge: 可能会因为与其它I/O请求的物理位置相邻而合并(merge)成一个I/O

• 被IO Scheduler依照调度策略发送给driver

• 被driver提交给硬件，经过HBA、电缆（光纤、网线等）、交换机（SAN或网络）、最后到达存储设备，设备完成IO请求之后再把结果发回。

根据以上步骤对应的时间戳就可以计算出I/O请求在每个阶段所消耗的时间：

用一张图来表示：

如果I/O性能慢的话，以上指标有助于进一步定位缓慢发生的地方：

附上event速查表：

注意以下几点： • Q2Q是表示两个reqeusts之间的间隔；而其他都是表示一个request的各个阶段的间隔。 • 和第2节中的IO的流程图一致，分为两个路径：上面绿色Q->G->I->D表示一个典型request（没有被merge的request）特有的阶段；下面红色为Q->M->D表示一个被merge的request特有的阶段；黄色部分表示公共阶段。 • Q2G一般比较小，若它比较大，说明分配不到struct request，中途经历了S(sleep)阶段。

二、IO路径分析工具blktrace

由于在iostat输出中，只能看到service time + wait time，因为对于评估一个磁盘或者云磁盘而言，service time才是衡量磁盘性能的核心指标和直接指标。很不幸iostat无法提供这个指标，但是blktrace可以。blktrace是一柄神器，很多工具都是基于该神器的：ioprof，seekwatcher，iowatcher，这个工具基本可以满足我们的对块设备请求的所有了解。

1、Blktrace工作原理 blktrace是block层的trace机制，它可以跟踪IO请求的生成、进入队列、发到driver以及完成等事件。blktrace包含3个组件：

• 一个内核模块 • 一个把内核模块跟踪到的IO信息导出到用户态的工具(blktrace命令) • 一些分析和展示IO信息的工具(blkparse, btt命令)

所以广义的blktrace包含这3个部分，狭义的blktrace只是blktrace命令。本文介绍广义的blktrace：包括使用blktrace命令导出IO信息，然后使用blkparse和btt分析展示。blktrace命令通过 debug file system 从内核导出数据： • blktrace从kernel接收数据并通过debug file system的buffer传递到用户态；debug file system默认是/sys/kernel/debug，可以使用blktrace命令的-r选项来覆盖。buffer的大小和数量默认分别是512KiB和4，可以通过-b和-n来覆盖。blktrace运行的的时候，可以看见debug file system里有一个block/{device}(默认是/sys/kernel/debug/block/{device})目录被创建出来，里面有一些trace{cpu}文件。

• blktrace默认地搜集所有trace到的事件，可以使用blktrace命令的-a选项来指定事件。

• blktrace把从内核接收到的数据写到当前目录，文件名为{device}.blktrace.{cpu}，内容是二进制数据（对于人来说是不可读的；blkparse用于解析这些二进制数据）。例如blktrace -d /dev/sdc会生成sdc.blktrace.0, sdc.blktrace.1, … sdc.blktrace.N-1个文件，N为cpu个数。也可使用-o选项来自定义{device}部分，这方便和blkparse结合使用：blktrace的-o参数对应blkparse的-i参数。

• blktrace默认地会一直运行，直到被ctrl-C停掉。可以使用-w选项来指定运行时间，单位是秒。 blktrace会区分两类请求:

• 文件系统请求(fs requests)：通常是用户态进程产生的，读写disk的特定位置和特定大小的数据。当然，也有可能由内核产生：flush脏页或sync文件系统的元数据(super block或journal block等)。

• SCSI命令(pc requests)：blktrace直接把SCSI命令发送到用户态，blkparse可以解析它。

2、Blktrace安装 yum安装方式

源码获取（你也可以从源码安装）

可以查看磁盘上的实时信息：

这个命令会连绵不绝地出现很多输出，当你输入ctrl＋C的时候，会停止。

命令采集信息，待所有信息采集完毕后，统一分析所有采集到的数据。搜集60s信息的命令如下：

首先blkparse可以将对应不同cpu的多个文件聚合成一个文件：

利用btt协助分析统计

注意：

文件解释：

blktrace 能够记录下IO所经历的各个步骤:

我们一起看下blktrace的输出参数解释：

• 第一个字段：8,0 这个字段是设备号 major device ID和minor device ID。 • 第二个字段：3 表示CPU • 第三个字段：11 序列号 • 第四个字段：0.009507758 Time Stamp是时间偏移 • 第五个字段：PID 本次IO对应的进程ID • 第六个字段：Event，这个字段非常重要，反映了IO进行到了那一步 • 第七个字段：R表示 Read， W是Write，D表示block，B表示Barrier Operation • 第八个字段：223490+56，表示的是起始block number 和 number of blocks，即我们常说的Offset 和 Size • 第九个字段： 进程名

其中第六个字段非常有用：每一个字母都代表了IO请求所经历的某个阶段。

Q – 即将生成IO请求 G – IO请求生成 I – IO请求进入IO Scheduler队列| D – IO请求进入driver| C – IO请求执行完毕

Summary包括CPU和device两个维度:

其中对于每个CPU或者对于Total： • Writes Queued：trace时间内，Q(queue)的requests个数；

• Writes Requeued：trace时间内，requeue数。requeue可能来自于multi-layer

• Write Dispatches：trace时间内，block layer发送到driver的requests数；

• Write Merges：trace时间内，merge的requests数；

• Writes Completed：trace时间内，完成的requests数；

• Timer unplugs：超时导致的unplug数？

Writes Queued与Writes Requeued之和是trace时间内block layer接收的requests总数（incomming requests）。Write Dispatches和Write Merges之和是trace时间内block layer发出的（到driver）requests数（outgoing requests）。进等于出，所以：

Write Dispatches是block layer发送到driver的requests数，但不是所有发送到driver的都完成了，其中有一部分被requeue了，即：

我们来分析一个io过程，将一块空白的磁盘格式化挂载一个目录，然后再写入一个文件

以上就是一次IO请求的生命周期，从actions看到，分别是QGPIUDC

案例分析： 案例一： 把/dev/sde(设备号:8,64)整个盘格式化成ext4，挂载到/mnt并使用fio写/mnt/fio-test-file (rw=randwrite ioengine=psync bs=4k fsync=1)，同时trace /dev/sde

我们尝试把一个特定request的事件给找出来(grep一个特定的起始sector号，而不是grep一个序列号):

这是一个Write+Sync请求，起始sector是7614368，大小是8个secotr(即4k)。它是一个典型的request：经历了Q->G->I->D-C几个阶段，总耗时：33.799933777-33.791608964 = 8324813纳秒 = 8.3毫秒。 Summary部分的Total(sde)：

另外，可以看到各个read指标都为0，因为fio全是写操作且大小和文件系统block对齐。可以对比还是全写操作但bs=5k(不再和文件系统block对齐)的情形，这时候read指标就不为0了，因为不对齐，文件系统需要把部分修改的block读出来，修改然后再写回去。

案例二： 把/dev/sde(设备号:8,64)分区并把/dev/sde2(设备号:8,66)格式化成ext4，挂载到/mnt并使用fio写/mnt/fio-test-file (rw=randwrite ioengine=psync bs=4k fsync=1)，同时还是trace /dev/sde：